fix(claude-code): dedupe compacted continuation sessions - #693

Problem

Claude Code context compaction can rewrite the beginning of a continued transcript. The imported-history cache grouped continuation siblings only by the first user-message UUID, so a compacted conversation could split into multiple families even though the files shared a compact-boundary UUID. The sidebar then showed multiple same-title sessions. When an older sibling was already open, the reveal overlay could also render it beside the canonical roster winner.

The repository performance guard also lacked a provider × raw transition × UI state × topology gate. Earlier dual-machine evidence could therefore validate transport while leaving Claude Code compaction, raw identity derivation, and active-row rescan behavior untested.

Solution

• Bump the Claude metadata parser to v11 and capture a bounded ancestry set: the first-user UUID plus up to 63 newest compact-boundary UUIDs.
• Elect continuation families as connected components of intersecting markers in O(session count × 64), keep only the newest top-level sibling listable, and stamp a stable continuationLineageId while preserving legacy group-key metadata.
• Carry the optional lineage id through the sidebar IPC/schema/store projection.
• When an older continuation is explicitly revealed because it is open, suppress the other roster sibling with the same lineage so the active session stays accessible without a duplicate row.
• Harden org2-performance-guard to separate provider ingestion, local identity/listability, UI hydration, cloud transport, and remote rendering; require raw provider transitions, assumption-breaking identity fixtures, active/open/pinned rescan coverage, and explicit untested matrix cells.

Potential risks

• Parser v11 causes one full Claude metadata reindex after upgrade so existing transcripts can acquire compact-boundary markers. This is a one-time local CPU/I/O cost; there is no database migration or persistence-format incompatibility.
• Marker storage is deliberately capped at 64. A conversation with more than 63 compactions and missing all intermediate transcript files could exceed the retained ancestry window and remain split.
• Continuation forks that reuse the same ancestry markers follow the existing continuation policy: only the newest sibling is listed. This PR extends that existing policy across compaction epochs rather than introducing a new fork distinction.
• The new IPC field is optional, so mixed-version or legacy cached rows remain compatible. Reverting the commit is sufficient rollback; the cache is rebuildable from source transcripts.
• The skill change intentionally makes future verification stricter and may produce a blocked verdict until relevant provider lifecycle cells are exercised. It changes no application runtime behavior and can be reverted independently.

Architecture audit

Covered discovery/parser state, watermark invalidation, cache metadata and election ownership, exact-id lookup, optional IPC/schema compatibility, session-store projection, and sidebar reveal behavior. Execution dispatch, cloud sync, database schema, and source transcript formats were intentionally unchanged.

Performance audit

• No new timer, poller, subscription, worker, or background task.
• Each row contributes at most 64 markers; election uses hash-based union/find rather than pairwise comparison.
• Initial v11 reindex is the only new full-file work. Later scans reuse the existing watermark/cache lifecycle and rewrite lineage metadata only when it changes.
• Live macOS minimized sampling over 15 seconds: CPU stayed at 0.0%; RSS moved from 303648 KB to 303584 KB. Visible idle sampling moved from 1.3% to 0.7% while startup work settled, with flat ~303 MB RSS.
• The skill update is documentation/metadata only and creates no runtime resource.

Verification

• cargo test -p orgtrack_core --lib -- --test-threads=1 — 537 passed, 8 ignored.
• cargo check -p org2 — passed.
• Pre-commit scoped cargo clippy for orgtrack_core — passed.
• pnpm exec tsc --noEmit --pretty false — passed.
• Targeted ESLint and Prettier checks for every changed TypeScript file — passed.
• vitest run for sidebar loader + continuation visibility — 23 passed.
• Full vitest run — 7852 passed, 1 pre-existing local-timezone failure in PrCommitsTab.test.ts; reproduced unchanged on the fix(key-vault): make CLI OAuth autodetect reliable #689/develop merge worktree. The failing test passes with TZ=UTC. The run also reported the existing Undici WebSocket/Event unhandled error from useCloudOrgSyncStatus.test.ts.
• Built an unsigned isolated macOS app bundle successfully.
• Real-machine scan against the three reported Claude transcripts: all three received the same lineage id and listability became 0 / 0 / 1; searching the title rendered exactly one sidebar row.
• Active-overlay scenario: opened the oldest transcript first, introduced the two continuation files, then manually rescanned Claude Code. The oldest row became unlistable but remained accessible as the active row, and the sidebar still rendered exactly one row.
• Official skill quick_validate.py in an isolated PyYAML environment — passed (Skill is valid!).
• Official generate_openai_yaml.py regenerated the skill interface metadata — passed.
• Prettier and repository pre-commit checks for the skill files — passed.
• Reverse-applied the new rejection rules to the previous fixtures: fabricated identical family keys are rejected, and Codex append/A-to-cloud evidence cannot be generalized to Claude Code compaction or active-old-row rescan.

UI evidence

Validated both the ordinary roster and the harder active-old-sibling state in the isolated app. A static screenshot is not attached because the acceptance signal is the absence of a second identical row; the manual flow above was cross-checked against the exact three-row SQLite listability/lineage state and the accessibility tree reporting one matching button.